不管自動化是甚麼，都給我來一點就是了

前一天說到了hosted pipeline，既然有這麼美好的東西，那我趕緊的來使用一下。這裡要先說一下，每一個組織都可以免費使用一條免費的hosted pipeline，但據說是之前被拿去挖礦，所以後面都變成申請制了。申請的步驟我就不特別貼了，因為筆者之前免費的已經申請過了，公司內現在就直接新台幣花下去了。

這邊先簡單介紹一下，在azure devops pipeline有分兩種，一種是傳統類型的卡片式pipeline，另外一種是純寫yaml的方式。

Classic Pipeline

這種卡片式的pipeline其實非常的好用，特別是對於我這種小白來說，要建立一個任務只要把卡片點一點拉一拉就好了。況且，微軟還寫了一大堆的模版，例如下圖中，我選擇了.net core的CI模版，可以看到他自動建立了 Restore->Build->Test->Publish->Publish Artifact。

不過筆者這次的任務，就都不是使用Classic Pipeline，一方面是Azure DevOps 如果使用Classic Pipeline，pipeline and release 這兩個功能很容易讓人混淆。再者就是權限控管上也因為這兩個功能是分開的，權限控管方式非常難調整，pipeline的版本軌跡也很不直觀。最後就是是微軟在最新的sprint225中有預先公告，未來classic pipeline預設會是關閉的，理由是增加安全性。

Yaml Pipeline

這種類型的pipeline就是純粹以yaml檔案進行定義，來驅動你希望hosted/self-hosted pipeline幫你去執行的任務。例如下面的yaml 檔，就是用最原始起始選擇ASP.NET Core做出來的範例。

# ASP.NET Core
# Build and test ASP.NET Core projects targeting .NET Core.
# Add steps that run tests, create a NuGet package, deploy, and more:
# https://docs.microsoft.com/azure/devops/pipelines/languages/dotnet-core

trigger:
- main

pool:
  vmImage: ubuntu-latest

variables:
  buildConfiguration: 'Release'

steps:
- script: dotnet build --configuration $(buildConfiguration)
  displayName: 'dotnet build $(buildConfiguration)'

因此你的所有pipeline yaml都是經過版本控管的方式進行，可以很直觀的看到每次修改的commit，對應的目的。太好了，我們可以開始寫yaml了嗎？

其實不然，因為既然是git，同樣的我們又要回到版本控管策略中討論一下了。

Pipeline repo branch design

不是說要說pipeline了？怎麼會又提到repo branch？其實這件事情內部曾經有過很大量的討論（說大量其實是我跟另外一位同仁而已，但的確討論很久），我們在討論的事情是，pipeline 的yaml或是sre 在編寫的k8s yaml是不是應該要跟source code放在同一個repo中？

之前在跟同事在gitlab上實驗性的進行協作時，我們放在一起其實有遇到問題，寫pipeline的我很容易打擾到在寫程式的同事。另外就是之前在Day8的時候有提及到，source code 的repo中，main branch 就是面對生產環境，dev branch就是面對測試環境。而我們對於main branch的嚴格審核制度(一定要科長approved），其實造成生產環境的pipeline yaml撰寫上很難進行。

到底軟體專案外部的yaml檔案該不該跟source code 放在同一個repo？

其實我覺得這沒有一定正確的答案，因為我知道放在一起的論點是，那些環境檔也是軟體專案的一部份，而且用產品的思維來看，其實放在一起反而直觀。

但是在我們的環境中，我們其實不是用產品思維在看我們公司的軟體專案，而是以運行系統在看我們的軟體專案，而且是分環境在看的。因此一套系統在不同的環境，就會有面對不同環境的資源問題，例如營運環境的nas跟測試環境就是不同ip。

因此，在看認真的思考之後，我決定要把yaml跟source code分開repo來放。後來在內部大量的討論的時後，爭論的題目其實是在GitOps 的那些k8s yaml，我最後找到了一篇文章來支持我的論點，我認為非常值得一看與思考。

stop-using-branches-deploying-different-gitops-environments。

該篇文章雖說是在寫GitOps，但我認為跟pipeline yaml跟k8s yaml其實都算是圍繞在軟體專案本身以外的一些環境設定檔案，所以其實是差不多的意思。

因此，我們的專案基本上目前就會有一個標配，那就是除了source code repo以外，至少一定要搭配一個pipeline的repo。那當然這樣的設計還是有一些眉角或是地雷會踩到，這個後面的實作中會帶給大家了解。

原廠技術文件一直都是告訴你工具可以怎麼用，別人的最佳實踐則是告訴你流程、設計原理以及踩過的雷。